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Abstract 


This note identifies the key infrastructure protocols of the Internet 
Protocol Suite for use in the Smart Grid. The target audience is 
those people seeking guidance on how to construct an appropriate 
Internet Protocol Suite profile for the Smart Grid. In practice, 
such a profile would consist of selecting what is needed for Smart 
Grid deployment from the picture presented here. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6272. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Baker & Meyer Informational [Page 1] 


Table of Contents 


hb 


RFC 6272 Internet Protocols for the Smart Grid June 2011 
Introduction 4 
The Internet Protocot Suite: 6 
-l. Internet Protocol Layers 6 
2.1.1. Application 7 
2.1.2. Transport 8 
2.1.3. Network : 8 
2.1.3.1. Internet Protocol 9 
2.1.3.2. Lower-Layer Networks 3 9 
2.1.4. Media Layers: ps and Link 9 
-2. Security Issues 9 
2.2.1. Physical and Data Link haven Security 10 
2.2.2. Network, Transport, and Application Layer Security D ae eh 
-3. Network Infrastructure $ 13 
2.3.1. Domain Name System (DNS) 13 
2.3.2. Network Management 13 
Specific Protocols 14 
.1. Security Toolbox S$. Sahn Mae St OMG ok. oe a, a a Se ch led 
3.1.1. Authentication, Authorization, and Accounting (AAA) = 44 
Isl 2 Network Layer Security 15 
3.1.3. Transport Layer Security 16 
3.1.4. Application Layer Security E7 
3 sAre5. Secure Shell 18 
3.1.6. Key Management Intrastruótūrss 18 
3.1.6.1. PKIX 18 
3.1.6.2. Kerberos 19 
.2. Network Layer 19 
3.2.1. IPv4/IPv6 Gnserstenee ‘advice 19 
3.2.1.1. Dual Stack Coexistence 19 
3.2.1.2. Tunneling Mechanism 20 
3.2.1.3. Translation between IPv4 and IPv6 "Networks 20 
3.2.2. Internet Protocol Version 4 os 21 
3.2.2.1. IPv4 Address Allocation and Assignment 22 
3.2.2.2. IPv4 Unicast Routing 22 
3.2.2.3. IPv4 Multicast Forwarding” and Routing. 22 
3.2.3. Internet Protocol Version 6 Ar 23 
3.2.3.1. IPv6 Address Allocation and Assi gnhent 23 
3.2.3.2. IPv6 Routing 24 
3.2.4. Routing for IPv4 and IPv6 24 
3.2.4.1. Routing Information Protocol 24 
3.2.4.2. Open Shortest Path First oi 8g Se De 
3.2.4.3. ISO Intermediate System to Intermediate. System E S] 
3.2.4.4. Border Gateway Protocol by Sg od Sse 25 
3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing 25 
3.2.4.6. Optimized Link State Routing Protocol 26 
3.2.4.7. Routing for Low-Power and Lossy Networks 26 

Baker & Meyer Informational [Page 2] 


RFC 6272 


w 


SQ RD 


ce Ve 


7.2. 


wh 
wh 


PWWWTWWDWW UW WW BWW WwW WwW Ww 


oe 
PAO 
.6. 


Internet Protocols for the Smart Grid June 2011 


=i Multicast Forwarding and Routing 
Protocol-Independent Multicast Routing 


27 
27 


ec to Lower-Layer Networks and Link layer 


Protocols 


Transport Layer 


alt. 
2h 
so% 
Aie 


User Datagram Protocòl (UDP) 

Transmission Control Protocol (TCP) 

Stream Control Transmission Protocol (SCTP) 
Datagram Congestion Control Protocol (DCCP) 


Infrastructure 


malts 
2. 
«o's 


Domain Name Systém 
Dynamic Host Configuration 
Network Time 


Network Management 


sate 
2. 


Simple Network Management “Protocol (SNMP) 
Network Configuration (NETCONF) Protocol 


Service and Resource Discovery 


ol 
z2 


Service Discovery 
Resource Discovery 


Other Applications 


sI 
eee. 


3. 


Session Initiation Protocol. 
Extensible Messaging and Presence protocol 
Calendaring 


Simplified View of the BUSINESS “Architectute 


Appendix 


A. 


DDP 


A. 


Baker & Meyer 


Security Considerations 
Acknowledgements 
References . 
Normative Reretences 
Informative References 


Example: Advanced Metering Infrastructure 


How to Structure a Network 
Salis 
23 
Model 1: AMI with Separate: Domains: : $ 
Model 2: AMI with Neighborhood Access to the Home 
Model 3: Collector Is an IP Router 


HAN Routing 
HAN Security 


Informational 


28 
28 
28 
29 
29 
30 
30 
30 
Sml 
SHl 
31 
31 
32 
33 
33 
33 
34 
34 
35 
35 
39 
40 
40 
40 
40 
41 
58 
59 
62 
62 
64 
65 
66 


[Page 3] 


RFC 6272 Internet Protocols for the Smart Grid June 2011 


1. Introduction 


This document provides Smart Grid designers with advice on how to 
best "profile" the Internet Protocol Suite (IPS) for use in Smart 
Grids. It provides an overview of the IPS and the key infrastructure 
protocols that are critical in integrating Smart Grid devices into an 
IP-based infrastructure. 


In the words of Wikipedia [SmartGrid]: 


A Smart Grid is a form of electricity network utilizing digital 
technology. A Smart Grid delivers electricity from suppliers to 
consumers using two-way digital communications to control 
appliances at consumers’ homes; this saves energy, reduces costs 
and increases reliability and transparency. It overlays the 
ordinary electrical Grid with an information and net metering 
system, that includes smart meters. Smart Grids are being 
promoted by many governments as a way of addressing energy 
independence, global warming and emergency resilience issues. 


A Smart Grid is made possible by applying sensing, measurement and 
control devices with two-way communications to electricity 
production, transmission, distribution and consumption parts of 
the power Grid that communicate information about Grid condition 
to system users, operators and automated devices, making it 
possible to dynamically respond to changes in Grid condition. 


A Smart Grid includes an intelligent monitoring system that keeps 
track of all electricity flowing in the system. It also has the 
capability of integrating renewable electricity such as solar and 
wind. When power is least expensive the user can allow the smart 
Grid to turn on selected home appliances such as washing machines 
or factory processes that can run at arbitrary hours. At peak 
times it could turn off selected appliances to reduce demand. 


Other names for a Smart Grid (or for similar proposals) include 
smart electric or power Grid, intelligent Grid (or intelliGrid), 
futureGrid, and the more modern interGrid and intraGrid. 


That description focuses on the implications of Smart Grid technology 
in the home of a consumer. In fact, data communications technologies 
of various kinds are used throughout the Grid, to monitor and 
maintain power generation, transmission, and distribution, as well as 
the operations and management of the Grid. One can view the Smart 
Grid as a collection of interconnected computer networks that 
connects and serves the needs of public and private electrical 
utilities and their customers. 
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At the time of this writing, there is no single document that can be 
described as comprising an internationally agreed standard for the 
Smart Grid; that is in part the issue being addressed in its 
development. The nearest approximations are probably the Smart Grid 
Interoperability Panel’s Conceptual Model [Model] and documents 
comprising [IEC61850]. 


The Internet Protocol Suite (IPS) provides options for numerous 
architectural components. For example, the IPS provides several 
choices for the traditional transport function between two systems: 
the Transmission Control Protocol (TCP) [RFC0793], the Stream Control 
Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion 
Control Protocol (DCCP) [RFC4340]. Another option is to select an 
encapsulation such as the User Datagram Protocol (UDP) [RFC0768], 
which essentially allows an application to implement its own 
transport service. In practice, a designer will pick a transport 
protocol that is appropriate to the problem being solved. 


The IPS is standardized by the Internet Engineering Task Force 
(IETF). IETF protocols are documented in the Request for Comments 
(RFC) series. Several RFCs have been written describing how the IPS 
should be implemented. These include: 


o Requirements for Internet Hosts - Communication Layers [RFC1122], 


o Requirements for Internet Hosts - Application and Support 
[RFC1123], 


o Requirements for IP Version 4 Routers [RFC1812], and 
o IPv6 Node Requirements [RFC4294]. 


At the time of this writing, RFC 4294 is in the process of being 
updated, in [IPv6-NODE-REQ]. 


This document is intended to provide Smart Grid architects and 
designers with a compendium of relevant RFCs (and to some extent, 
Internet Drafts), and is organized as an annotated list of RFCs. To 
that end, the remainder of this document is organized as follows: 


o Section 2 describes the Internet Architecture and its protocol 
suite. 


o Section 3 outlines a set of protocols that may be useful in Smart 
Grid deployment. It is not exhaustive. 


o Finally, Section 4 provides an overview of the business 
architecture embodied in the design and deployment of the IPS. 
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2. The Internet Protocol Suite 


Before enumerating the list of Internet protocols relevant to Smart 
Grid, we discuss the layered architecture of the IPS, the functions 
of the various layers, and their associated protocols. 


2.1. Internet Protocol Layers 


While Internet architecture uses the definitions and language similar 
to language used by the ISO Open System Interconnect (ISO-OST) 
reference model (Figure 1), it actually predates that model. Asa 
result, there is some skew in terminology. For example, the ISO-OSI 
model uses "end system" while the Internet architecture uses "host". 
Similarly, an "intermediate system" in the ISO-OSI model is called an 
"internet gateway" or "router" in Internet parlance. Notwithstanding 
these differences, the fundamental concepts are largely the same. 


+-------------------- + 
| Application Layer | 
+-------------------- + 
| Presentation Layer | 
+------------------—- + 
| Session Layer | 
+-------------------- + 
| Transport Layer | 
+-------------------- + 
| Network Layer | 
+-------------------- + 
| Data Link Layer 

+-------------------- + 
| Physical Layer | 
+-------------------- + 


Figure 1: The ISO OSI Reference Model 


The structure of the Internet reference model is shown in Figure 2. 


Baker & Meyer Informational [Page 6] 


RFC 6272 Internet Protocols for the Smart Grid June 2011 


+--------------------------------- + 
|Application | 
+--------------------------- + 
| Application Protocol | | 
+---------- +---------------- + | 
Encoding Session Control 
| | | | | 
| +---------- +---------------- + | 
4+--------------------------------- + 
Transport 
+--------------------------- + 
| | Transport Layer | | 
| +--------------------------- + | 
4+--------------------------------- + 
|Network | 
| +--------------------------—- + | 
| | Internet Protocol | | 
4--------------------------- + 
| | Lower Network Layers | | 
| +--------------------------- + | 
4+--------------------------------- + 
|Media Layers | 
4+--------------------------- + 
| | Data Link Layer | | 
| +--------------------------- + | 
| | Physical Layer | | 
| +--------------------------- + | 
4+--------------------------------- + 


Figure 2: The Internet Reference Model 
2.1.1. Application 


In the Internet model, the Application, Presentation, and Session 
layers are compressed into a single entity called "the application". 
For example, the Simple Network Management Protocol (SNMP) [RFC3411] 
describes an application that encodes its data in an ASN.1 profile 
and engages in a session to manage a network element. The point here 
is that in the Internet, the distinction between these layers exists 
but is not highlighted. Further, note that in Figure 2, these 
functions are not necessarily cleanly layered: the fact that an 
application protocol encodes its data in some way and that it manages 
sessions in some way doesn’t imply a hierarchy between those 
processes. Rather, the application views encoding, session 
management, and a variety of other services as a tool set that it 
uses while doing its work. 
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2.1.2. Transport 


The term "transport" is perhaps among the most confusing concepts in 
the communication architecture, to a large extent because people with 
various backgrounds use it to refer to "the layer below that which I 
am interested in, which gets my data to my peer". For example, 
optical network engineers refer to optical fiber and associated 
electronics as "the transport", while web designers refer to the 
Hypertext Transfer Protocol (HTTP) [RFC2616] (an application layer 
protocol) as "the transport". 


In the Internet protocol stack, the "transport" is the lowest 
protocol layer that travels end-to-end unmodified, and it is 
responsible for end-to-end data delivery services. In the Internet, 
the transport layer is the layer above the network layer. Transport 
layer protocols have a single minimum requirement: the ability to 
multiplex several applications on one IP address. UDP [RFC0768], TCP 
[RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] each 
accomplish this using a pair of port numbers, one for the sender and 
one for the receiver. A port number identifies an application 
instance, which might be a general "listener" that peers or clients 
may open sessions with, or a specific correspondent with such a 
"listener". The session identification in an IP datagram is often 
called the "five-tuple", and consists of the source and destination 
IP addresses, the source and destination ports, and an identifier for 
the transport protocol in use. 


In addition, the responsibilities of a specific transport layer 
protocol typically include the delivery of data (either as a stream 
of messages or a stream of bytes) in a stated sequence with stated 
expectations regarding delivery rate and loss. For example, TCP will 
reduce its rate in response to loss, as a congestion control trigger, 
while DCCP accepts some level of loss if necessary to maintain 
timeliness. 


2.1.3. Network 


The main function of the network layer is to identify a remote 
destination and deliver data to it. In connection-oriented networks 
such as Multi-protocol Label Switching (MPLS) [RFC3031] or 
Asynchronous Transfer Mode (ATM), a path is set up once, and data is 
delivered through it. In connectionless networks such as Ethernet 
and IP, data is delivered as datagrams. Each datagram contains both 
the source and destination network layer addresses, and the network 
is responsible for delivering it. In the Internet Protocol Suite, 
the Internet Protocol is the network that runs end to end. It may be 
encapsulated over other LAN and WAN technologies, including both IP 
networks and networks of other types. 
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2.1.3.1. Internet Protocol 


IPv4 and IPv6, each of which is called the Internet Protocol, are 


connectionless ("datagram") architectures. They are designed as 
common elements that interconnect network elements across a network 
of lower-layer networks. In addition to the basic service of 


identifying a datagram’s source and destination, they offer services 
to fragment and reassemble datagrams when necessary, assist in 
diagnosis of network failures, and carry additional information 
necessary in special cases. 


The Internet layer provides a uniform network abstraction network 
that hides the differences between various network technologies. 

This is the layer that allows diverse networks such as Ethernet, 
802.15.4, etc. to be combined into a uniform IP network. New network 
technologies can be introduced into the IP Protocol Suite by defining 
how IP is carried over those technologies, leaving the other layers 
of the IPS and applications that use those protocol unchanged. 


2.1.3.2. Lower-Layer Networks 


The network layer can be recursively subdivided as needed. This may 
be accomplished by tunneling, in which an IP datagram is encapsulated 
in another IP header for delivery to a decapsulator. IP is 
frequently carried in Virtual Private Networks (VPNs) across the 
public Internet using tunneling technologies such as the Tunnel mode 
of IPsec, IP-in-IP, and Generic Route Encapsulation (GRE) [RFC2784]. 
In addition, IP is also frequently carried in circuit networks such 
as MPLS [RFC4364], GMPLS, and ATM. Finally, IP is also carried over 
wireless networks (IEEE 802.11, 802.15.4, or 802.16) and switched 
Ethernet (IEEE 802.3) networks. 


2.1.4. Media Layers: Physical and Link 


At the lowest layer of the IP architecture, data is encoded in 
messages and transmitted over the physical media. While the IETF 
specifies algorithms for carrying IPv4 and IPv6 various media types, 
it rarely actually defines the media -- it happily uses 
specifications from IEEE, ITU, and other sources. 


2.2. Security Issues 


While complaining about the security of the Internet is popular, it 
is important to distinguish between attacks on protocols and attacks 
on users (e.g., phishing). Attacks on users are largely independent 
of protocol details, reflecting interface design issues or user 
education problems, and are out of scope for this document. Security 
problems with Internet protocols are in scope, of course, and can 
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often be mitigated using existing security features already specified 
for the protocol, or by leveraging the security services offered by 
other IETF protocols. See the Security Assessment of the 
Transmission Control Protocol (TCP) [TCP-SEC] and the Security 
Assessment of the Internet Protocol version 4 [IP-SEC] for more 
information on TCP and IPv4 issues, respectively. 


These solutions do, however, need to get deployed as well. The road 
to widespread deployment can sometimes be painful since often 
multiple stakeholders need to take actions. Experience has shown 
that this takes some time, and very often only happens when the 
incentives are high enough in relation to the costs. 


Furthermore, it is important to stress that available standards are 
important, but the range of security problems is larger than a 
missing standard; many security problems are the result of 
implementation bugs and the result of certain deployment choices. 
While these are outside the realm of standards development, they play 
an important role in the security of the overall system. Security 
has to be integrated into the entire process. 


The IETF takes security seriously in the design of their protocols 
and architectures; every IETF specification has to have a Security 
Considerations section to document the offered security threats and 
countermeasures. RFC 3552 [RFC3552] provides recommendations on 
writing such a Security Considerations section. It also describes 
the classical Internet security threat model and lists common 
security goals. 


In a nutshell, security has to be integrated into every protocol, 
protocol extension, and consequently, every layer of the protocol 
stack to be useful. We illustrate this also throughout this document 
with references to further security discussions. Our experience has 
shown that dealing with security as an afterthought does not lead to 
the desired outcome. 


The discussion of security threats and available security mechanisms 
aims to illustrate some of the design aspects that commonly appear. 


2.2.1. Physical and Data Link Layer Security 


At the physical and data link layers, threats generally center on 
physical attacks on the network -- the effects of backhoes, 
deterioration of physical media, and various kinds of environmental 
noise. Radio-based networks are subject to signal fade due to 
distance, interference, and environmental factors; it is widely noted 
that IEEE 802.15.4 networks frequently place a metal ground plate 
between the meter and the device that manages it. Fiber was at one 
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time deployed because it was believed to be untappable; we have since 
learned to tap it by bending the fiber and collecting incidental 
light, and we have learned about backhoes. As a result, some 
installations encase fiber optic cable in a pressurized sheath, both 
to quickly identify the location of a cut and to make it more 
difficult to tap. 


While there are protocol behaviors that can detect certain classes of 
physical faults, such as keep-alive exchanges, physical security is 
generally not considered to be a protocol problem. 


For wireless transmission technologies, eavesdropping on the 
transmitted frames is also typically a concern. Additionally, those 
operating networks may want to ensure that access to their 
infrastructure is restricted to those who are authenticated and 


authorized (typically called ’network access authentication’). This 
procedure is often offered by security primitives at the data link 
layer. 


2.2.2. Network, Transport, and Application Layer Security 


At the network, transport, and application layers, it is common to 
demand a few basic security requirements, commonly referred to as CIA 
(Confidentiality, Integrity, and Availability): 


1. Confidentiality: Protect the transmitted data from unauthorized 
disclosure (i.e., keep eavesdroppers from learning what was 
transmitted). For example, for trust in e-commerce applications, 
credit card transactions are exchanged encrypted between the Web 
browser and a Web server. 


2. Integrity: Protect against unauthorized changes to exchanges, 
including both intentional change or destruction and accidental 
change or loss, by ensuring that changes to exchanges are 
detectable. It has two parts: one for the data and one for the 
peers. 


* Peers need to verify that information that appears to be from 
a trusted peer is really from that peer. This is typically 
called ‘data origin authentication’. 


* Peers need to validate that the content of the data exchanged 
is unmodified. The term typically used for this property is 


‘data integrity’. 


3. Availability: Ensure that the resource is accessible by 
mitigating of denial-of-service attacks. 
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To this we add authenticity, which requires that the communicating 
peers prove that they are in fact who they say they are to each other 
(i.e., mutual authentication). This generally means knowing "who" 
the peer is, and that they demonstrate the possession of a "secret" 
as part of the security protocol interaction. 


The following three examples aim to illustrate these security 
requirements. 


One common attack against a TCP session is to bombard the session 
with reset messages. Other attacks against TCP include the "SYN 
flooding" attack, in which an attacker attempts to exhaust the memory 
of the target by creating TCP state. In particular, the attacker 
attempts to exhaust the target’s memory by opening a large number of 
unique TCP connections, each of which is represented by a 
Transmission Control Block (TCB). The attack is successful if the 
attacker can cause the target to fill its memory with TCBs. 


A number of mechanisms have been developed to deal with these types 
of denial-of-service attacks. One, "SYN Cookies", delays state 
establishment on the server side to a later phase in the protocol 
exchange. Another mechanism, specifically targeting the reset attack 
cited above, provides authentication services in TCP itself to ensure 
that fake resets are rejected. 


Another approach would be to offer security protection already at a 
lower layer, such as IPsec (see Section 3.1.2) or TLS (see 

Section 3.1.3), so that a host can identify legitimate messages and 
discard the others, thus mitigating any damage that may have been 
caused by the attack. 


Another common attack involves unauthorized access to resources. For 
example, an unauthorized party might try to attach to a network. To 
protect against such an attack, an Internet Service Provider (ISP) 
typically requires network access authentication of new hosts 
demanding access to the network and to the Internet prior to offering 
access. This exchange typically requires authentication of that 
entity and a check in the ISPs back-end database to determine whether 
corresponding subscriber records exist and are still valid (e.g., 
active subscription and sufficient credits). 


From the discussion above, establishing a secure communication 
channel is clearly an important concept frequently used to mitigate a 
range of attacks. Unfortunately, focusing only on channel security 
may not be enough for a given task. Threat models have evolved and 
even some of the communication endpoints cannot be considered fully 
trustworthy, i.e., even trusted peers may act maliciously. 


Baker & Meyer Informational [Page 12] 


RFC 6272 Internet Protocols for the Smart Grid June 2011 


Furthermore, many protocols are more sophisticated in their protocol 
interaction and involve more than two parties in the protocol 
exchange. Many of the application layer protocols, such as email, 
instant messaging, voice over IP, and presence-based applications, 
fall into this category. With this class of protocols, secure data, 
such as DNS records, and secure communications with middleware, 
intermediate servers, and supporting applications need to be 
considered as well as the security of the direct communication. A 
detailed treatment of the security threats and requirements of these 
multi-party protocols is beyond this specification but the interested 
reader is referred to the above-mentioned examples for an 
illustration of what technical mechanisms have been investigated and 
proposed in the past. 


2.3. Network Infrastructure 
While the following protocols are not critical to the design of a 


specific system, they are important to running a network, and as such 
are surveyed here. 


2.3.1. Domain Name System (DNS) 


The DNS’ main function is translating names to numeric IP addresses. 
While this is not critical to running a network, certain functions 
are made a lot easier if numeric addresses can be replaced with 
mnemonic names. This facilitates renumbering of networks and 
generally improves the manageability and serviceability of the 
network. DNS has a set of security extensions called DNSSEC, which 
can be used to provide strong cryptographic authentication to the 
DNS. DNS and DNSSEC are discussed further in Section 3.4.1. 


2.3.2. Network Management 


Network management has proven to be a difficult problem. As such, 
various solutions have been proposed, implemented, and deployed. 
Each solution has its proponents, all of whom have solid arguments 
for their viewpoints. The IETF has two major network management 
solutions for device operation: SNMP, which is ASN.1-encoded and is 
primarily used for monitoring of system variables, and NETCONF 
[RFC4741], which is XML-encoded and primarily used for device 
configuration. 


Another aspect of network management is the initial provisioning and 
configuration of hosts, which is discussed in Section 3.4.2. Note 
that Smart Grid deployments may require identity authentication and 
authorization (as well as other provisioning and configuration) that 
may not be within the scope of either DHCP or Neighbor Discovery. 
While the IP Protocol Suite has limited support for secure 
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provisioning and configuration, these problems have been solved using 
IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0]. 


3. Specific Protocols 


In this section, having briefly laid out the IP architecture and some 
of the problems that the architecture tries to address, we introduce 
specific protocols that might be appropriate to various Smart Grid 
use cases. Use cases should be analyzed along with privacy, 
Authentication, Authorization, and Accounting (AAA), transport, and 
network solution dimensions. The following sections provide guidance 
for such analysis. 


3.1. Security Toolbox 


As noted, a key consideration in security solutions is a good threat 
analysis coupled with appropriate mitigation strategies at each 
layer. The IETF has over time developed a number of building blocks 
for security based on the observation that protocols often demand 
Similar security services. The following sub-sections outline a few 
of those commonly used security building blocks. Reusing them offers 
several advantages, such as availability of open source code, 
experience with existing systems, a number of extensions that have 
been developed, and the confidence that the listed technologies have 
been reviewed and analyzed by a number of security experts. 


It is important to highlight that in addition to the mentioned 
security tools, every protocol often comes with additional, often 
unique security considerations that are specific to the domain in 
which the protocol operates. Many protocols include features 
specifically designed to mitigate these protocol-specific risks. In 
other cases, the security considerations will identify security- 
relevant services that are required from other network layers to 
achieve appropriate levels of security. 


3.1.1. Authentication, Authorization, and Accounting (AAA) 


While the term AAA sounds generic and applicable to all sorts of 
security protocols, it has been, in the IETF, used in relation to 
network access authentication and is associated with the RADIUS 
([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in 
particular. 


The authentication procedure for network access aims to deal with the 
task of verifying that a peer is authenticated and authorized prior 
to accessing a particular resource (often connectivity to the 
Internet). Typically, the authentication architecture for network 
access consists of the following building blocks: the Extensible 


Baker & Meyer Informational [Page 14] 


RFC 6272 Internet Protocols for the Smart Grid June 2011 


Authentication Protocol (EAP [RFC4017]) as a container to encapsulate 
EAP methods, an EAP Method (as a specific way to perform 
cryptographic authentication and key exchange, such as described in 
RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries 
EAP payloads between the end host and a server-side entity (such as a 
network access server), and a way to carry EAP payloads to back-end 
server infrastructure (potentially in a cross-domain scenario) to 
provide authorization and accounting functionality. The latter part 
is provided by RADIUS and Diameter. To carry EAP payloads between 
the end host and a network access server, different mechanisms have 
been standardized, such as the Protocol for Carrying Authentication 
for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X]. 

For access to remote networks, such as enterprise networks, the 
ability to utilize EAP within IKEv2 [RFC5996] has also been 
developed. 


More recently, the same architecture with EAP and RADIUS/Diameter is 
being reused for application layer protocols. More details about 
this architectural variant can be found in [ABFAB-ARCH]. 


3.1.2. Network Layer Security 


IP security, as described in [RFC4301], addresses security at the IP 
layer, provided through the use of a combination of cryptographic and 
protocol security mechanisms. It offers a set of security services 
for traffic at the IP layer, in both the IPv4 and IPv6 environment. 
The set of security services offered includes access control, 
connectionless integrity, data origin authentication, detection and 
rejection of replays (a form of partial sequence integrity), 
confidentiality (via encryption), and limited traffic-—flow 
confidentiality. These services are provided at the IP layer, 
offering protection in a standard fashion for all protocols that may 
be carried over IP (including IP itself). 


The architecture foresees a split between the rather time-consuming 
(a) authentication and key exchange protocol step that also 
establishes a security association (a data structure with keying 
material and security parameters) and (b) the actual data traffic 
protection. 


For the former step, the Internet Key Exchange protocol version 2 
(IKEv2 [RFC5996]) is the most recent edition of the standardized 
protocol. IKE negotiates each of the cryptographic algorithms that 
will be used to protect the data independently, somewhat like 
selecting items a la carte. 


For the actual data protection, two types of protocols have 
historically been used, namely the IP Authentication Header (AH) 
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[RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. 
The two differ in the security services they offer; the most 
important distinction is that ESP offers confidentiality protection 
while AH does not. Since ESP can also provide authentication 
services, most recent protocol developments making use of IPsec only 
specify use of ESP and do not use AH. 


In addition to these base line protocol mechanisms a number of 
extensions have been developed for IKEv2 (e.g., an extension to 
perform EAP-only authentication [RFC5998]) and since the architecture 
supports flexible treatment of cryptographic algorithms a number of 
them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835] 
for AH and ESP). 


3.1.3. Transport Layer Security 


Transport Layer Security v1.2 [RFC5246] are security services that 
protect data above the transport layer. The protocol allows client/ 
server applications to communicate in a way that is designed to 
prevent eavesdropping, tampering, or message forgery. TLS is 
application protocol independent. 


TLS is composed of two layers: the TLS Record protocol and the TLS 
Handshake protocol. The TLS Record protocol provides connection 
security that has two basic properties: (a) confidentiality 
protection and (b) integrity protection. 


The TLS Handshake protocol allows the server and client to 
authenticate each other and to negotiate an encryption algorithm and 
cryptographic keys before the application protocol transmits or 
receives its first byte of data. The negotiated parameters and the 
derived keying material is then used by the TLS Record protocol to 
perform its job. 


Unlike IKEv2/IPsec, TLS negotiates these cryptographic parameters in 
suites, so-called cipher suites’. Examples of cipher suites that 
can be negotiated with TLS include Elliptic Curve Cryptography (ECC) 
[RFC4492] [RFC5289] [AES-CCM-ECC], Camellia [RFC5932], and the Suite 
B Profile [RFC5430]. [IEC62351-3] outlines the use of different TLS 
cipher suites for use in the Smart Grid. The basic cryptographic 
mechanisms for ECC have been documented in [RFC6090]. 


TLS must run over a reliable transport channel -- typically TCP. In 
order to offer the same security services for unreliable datagram 
traffic, such as UDP, the Datagram Transport Layer Security (DTLS 
[RFC4347] [DTLS]) was developed. 
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3.1.4. Application Layer Security 


In certain cases, the application layer independent security 
mechanisms described in the previous sub-sections are not sufficient 
to deal with all the identified threats. For this purpose, a number 
of security primitives are additionally available at the application 
layer where the semantic of the application can be considered. 


We will focus our description on a few mechanisms that are commonly 
used throughout the Internet. 


Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation 
syntax to sign, digest, authenticate, or encrypt arbitrary message 
content. It also allows arbitrary attributes, such as signing time, 
to be signed along with the message content, and it provides for 
other attributes such as countersignatures to be associated with a 


signature. The CMS can support a variety of architectures for 
certificate-based key management, such as the one defined by the PKIX 
(Public Key Infrastructure using X.509) working group [RFC5280]. The 


CMS has been leveraged to supply security services in a variety of 
protocols, including secure email [RFC5751], key management [RFC5958] 
[RFC6031], and firmware updates [RFC4108]. 


Related work includes the use of digital signatures on XML-encoded 
documents, which has been jointly standardized by W3C and the IETF 
[RFC3275]. Digitally signed XML is a good choice where applications 
natively support XML-encoded data, such as the Extensible Messaging 
and Presence Protocol (XMPP). 


More recently, the work on delegated authentication and authorization 
often demanded by Web applications have been developed with the Open 
Web Authentication (OAuth) protocol [RFC5849] [OAUTHv2]. OAuth is 
used by third-party applications to gain access to protected 
resources (such as energy consumption information about a specific 
household) without having the resource owner share its long-term 
credentials with that third-party. In OAuth, the third-party 
application requests access to resources controlled by the resource 
owner and hosted by the resource server, and is issued a different 
set of credentials than those of the resource owner. More 
specifically, the third-party applications obtain an access token 
during the OAuth protocol exchange. This token denotes a specific 
scope, duration, and other access attributes. As a result, it 
securely gains access to the protected resource with the consent of 
the resource owner. 
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3.1.5. Secure Shell 


The Secure Shell (SSH) protocol [RFC4253] has been widely used by 
administrators and others for secure remote login, but is also usable 
for secure tunneling. More recently, protocols have chosen to layer 
on top of SSH for transport security services; for example, the 
NETCONF network management protocol (see Section 3.5.2) uses SSH as 
its main communications security protocol. 


3.1.6. Key Management Infrastructures 


All of the security protocols discussed above depend on cryptography 
for security, and hence require some form of key management. Most 
IETF protocols at least nominally require some scalable form of key 
management to be defined as mandatory to implement; indeed the lack 
of such key management features has in the past been a reason to 
delay approval of protocols. There are two generic key management 
schemes that are widely used by other Internet protocols, PKIX and 
Kerberos, each of which is briefly described below. 


3.1.6.1. PKIX 


Public Key Infrastructure (PKI) refers to the kind of key management 
that is based on certification authorities (CAs) issuing public key 
certificates for other key holders. By chaining from a trust anchor 
(a locally trusted copy of a CA public key) down to the public key of 
some protocol peer, PKI allows for secure binding between keys and 
protocol-specific names, such as email addresses, and hence enables 
security services such as data and peer authentication, data 
integrity, and confidentiality (encryption). 


The main Internet standard for PKI is [RFC5280], which is a profile 
of the X.509 public key certificate format. There are a range of 
private and commercial CAs operating today providing the ability to 
manage and securely distribute keys for all protocols that use public 
key certificates, e.g., TLS and S/MIME. In addition to the profile 
standard, the PKIX working group has defined a number of management 
protocols (e.g., [RFC5272] and [RFC4210]) as well as protocols for 
handling revocation of public key certificates such as the Online 
Certificate Status Protocol (OCSP) [RFC2560]. 


PKI is generally perceived to better handle use-cases spanning 
multiple independent domains when compared to Kerberos. 
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3.1.6.2. Kerberos 


The Kerberos Network Authentication System [RFC4120] is commonly used 
within organizations to centralize authentication, authorization, and 
policy in one place. Kerberos natively supports usernames and 
passwords as the basis of authentication. With Public Key 
Cryptography for Initial Authentication in Kerberos (PKINIT) 
[RFC4556], Kerberos supports certificate or public-—key-—based 
authentication. This may provide an advantage by concentrating 
policy about certificate validation and mapping of certificates to 
user accounts in one place. Through the GSS-API [RFC1964] [RFC2743] 
[RFC4121], Kerberos can be used to manage authentication for most 
applications. While Kerberos works best within organizations and 
enterprises, it does have facilities that permit authentication to be 
shared between administrative domains. 


3.2. Network Layer 


The IPS specifies two network layer protocols: IPv4 and IPv6é. The 
following sections describe the IETF’s coexistence and transition 
mechanisms for IPv4 and IPv6. 


Note that on 3 February 2011, the IANA’s IPv4 free pool (the pool of 
available, unallocated IPv4 addresses) was exhausted, and the 
Regional Internet Registrars’ (RIRs’) free pools are expected to be 
exhausted during the coming year, if not sooner. The IETF, the IANA, 
and the RIRs recommend that new deployments use IPv6, and that IPv4 
infrastructures be supported via the mechanisms described in 

Section 3.2.1. 


3.2.1. IPv4/IPv6 Coexistence Advice 
The IETF has specified a variety of mechanisms designed to facilitate 
IPv4/IPv6 coexistence. The IETF actually recommends relatively few 
of them: the current advice to network operators is found in 
Guidelines for Using IPv6 Transition Mechanisms [RFC6180]. The 
thoughts in that document are replicated here. 

3.2.1.1. Dual Stack Coexistence 
The simplest coexistence approach is to 


O provide a network that routes both IPv4 and IPv6, 


o ensure that servers and their applications similarly support both 
protocols, and 
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o require that all new systems and applications purchased or 
upgraded support both protocols. 


The net result is that over time all systems become protocol 
agnostic, and that eventually maintenance of IPv4 support becomes a 
business decision. This approach is described in the Basic 
Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]. 


3.2.1.2. Tunneling Mechanism 


In those places in the network that support only IPv4, the simplest 
and most reliable approach to coexistence is to provide virtual 
connectivity using tunnels or encapsulations. Early in IPv6 
deployment, this was often done using static tunnels. A more dynamic 
approach is documented in IPv6 Rapid Deployment on IPv4 
Infrastructures (6rd) [RFC5569]. 


3.2.1.3. Translation between IPv4 and IPv6 Networks 


In those cases where an IPv4-only host would like to communicate with 
an IPv6-only host (or vice versa), a need for protocol translation 
may be indicated. At first blush, protocol translation may appear 
trivial; on deeper inspection, it turns out that protocol translation 
can be complicated. 


The most reliable approach to protocol translation is to provide 
application layer proxies or gateways, which natively enable 
application-to-application connections using both protocols and can 
use whichever is appropriate. For example, a web proxy might use 
both protocols and as a result enable an IPv4-only system to run HTTP 
across an IPv6-only network or to a web server that implements only 
IPv6. Since this approach is a service of a protocol-agnostic 
server, it is not the subject of standardization by the IETF. 


For those applications in which network layer translation is 
indicated, the IETF has designed a translation mechanism, which is 
described in the following documents: 

o Framework for IPv4/IPv6 Translation [RFC6144] 

o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052] 

o DNS extensions [RFC6147] 


o IP/ICMP Translation Algorithm [RFC6145] 


o Translation from IPv6 Clients to IPv4 Servers [RFC6146] 
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As with IPv4/IPv4 Network Address Translation, translation between 
IPv4 and IPv6 has limited real world applicability for an application 
protocol that carries IP addresses in its payload and expects those 
addresses to be meaningful to both client and server. However, for 
those protocols that do not, protocol translation can provide a 
useful network extension. 


Network-based translation provides for two types of services: 
stateless (and therefore scalable and load-sharable) translation 
between IPv4 and IPv6 addresses that embed an IPv4 address in them, 
and stateful translation similar to IPv4/IPv4 translation between 
IPv4 addresses. The stateless mode is straightforward to implement, 
but due to the embedding, requires IPv4 addresses to be allocated to 
an otherwise IPv6é-only network, and is primarily useful for IPv4- 
accessible servers implemented in the IPv6 network. The stateful 
mode allows clients in the IPv6 network to access servers in the IPv4 
network, but does not provide such service for IPv4 clients accessing 
IPv6 peers or servers with general addresses; it has the advantage 
that it does not require that a unique IPv4 address be embedded in 
the IPv6 address of hosts using this mechanism. 


Finally, note that some site networks are IPv6 only while some 
transit networks are IPv4 only. In these cases, it may be necessary 
to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4. 


3.2.2. Internet Protocol Version 4 


IPv4 [RFC0O791] and the Internet Control Message Protocol (ICMP) 
[RFC0792] comprise the IPv4 network layer. IPv4 provides unreliable 
delivery of datagrams. 


IPv4 also provides for fragmentation and reassembly of long datagrams 
for transmission through networks with small Maximum Transmission 
Units (MTU). The MTU is the largest packet size that can be 
delivered across the network. In addition, the IPS provides ICMP 
[RFC0792], which is a separate protocol that enables the network to 
report errors and other issues to hosts that originate problematic 
datagrams. 


IPv4 originally supported an experimental type of service field that 
identified eight levels of operational precedence styled after the 
requirements of military telephony, plus three and later four bit 
flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 
[RFC2328] interpreted as control traffic; this control traffic is 
assured of not being dropped when queued or upon receipt, even if 
other traffic is being dropped. These control bits turned out to be 
less useful than the designers had hoped. They were replaced by the 
Differentiated Services Architecture [RFC2474] [RFC2475], which 
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contains a six-bit code point used to select an algorithm (a "per-hop 
behavior") to be applied to the datagram. The IETF has also produced 
a set of Configuration Guidelines for DiffServ Service Classes 
[RFC4594], which describes a set of service classes that may be 
useful to a network operator. 


3.2.2.1. IPv4 Address Allocation and Assignment 


IPv4 addresses are administratively assigned, usually using automated 
methods, using the Dynamic Host Configuration Protocol (DHCP) 


[RFC2131]. On most interface types, neighboring systems identify 
each others’ addresses using the Address Resolution Protocol (ARP) 
[RFC0826]. 


3.2.2.2. IPv4 Unicast Routing 


Routing for the IPv4 Internet is accomplished by routing applications 
that exchange connectivity information and build semi-static 


destination routing databases. If a datagram is directed to a given 
destination address, the address is looked up in the routing 
database, and the most specific ("longest") prefix found that 


contains it is used to identify the next-hop router or the end system 
to which it will be delivered. This is not generally implemented on 
hosts, although it can be; a host normally sends datagrams to a 
router on its local network, and the router carries out the intent. 


IETF specified routing protocols include RIP Version 2 [RFC2453], OSI 
IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 
[RFC4271]. Active research exists in mobile ad hoc routing and other 
routing paradigms; these result in new protocols and modified 
forwarding paradigms. 


3.2.2.3. IPv4 Multicast Forwarding and Routing 


IPv4 was originally specified as a unicast (point to point) protocol, 
and was extended to support multicast in [RFC1112]. This uses the 
Internet Group Management Protocol [RFC3376] [RFC4604] to enable 
applications to join multicast groups, and for most applications uses 
Source-Specific Multicast [RFC4607] for routing and delivery of 
multicast messages. 


An experiment carried out in IPv4 that is not part of the core 
Internet architecture but may be of interest in the Smart Grid is the 
development of so-called "Reliable Multicast". This is "so-called" 
because it is not "reliable" in the strict sense of the word -- it is 
perhaps better described as "enhanced reliability". A best effort 
network by definition can lose traffic, duplicate it, or reorder it, 
something as true for multicast as for unicast. Research in 
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"Reliable Multicast" technology intends to improve the probability of 
delivery of multicast traffic. 


In that research, the IETF imposed guidelines [RFC2357] on the 
research community regarding what was desirable. Important results 
from that research include a number of papers and several proprietary 
protocols including some that have been used in support of business 
operations. RFCs in the area include The Use of Forward Error 
Correction (FEC) in Reliable Multicast [RFC3453], the Negative- 
acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol 
[RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) 
[RFC4410]. 


3.2.3. Internet Protocol Version 6 


IPv6 [RFC2460], with the Internet Control Message Protocol "v6" 
[RFC4443], constitutes the next generation protocol for the Internet. 
IPv6 provides for transmission of datagrams from source to 
destination hosts, which are identified by fixed-length addresses. 


IPv6 also provides for fragmentation and reassembly of long datagrams 
by the originating host, if necessary, for transmission through 
"small packet" networks. ICMPv6, which is a separate protocol 
implemented along with IPv6, enables the network to report errors and 
other issues to hosts that originate problematic datagrams. 


IPv6 adopted the Differentiated Services Architecture [RFC2474] 
[RFC2475], which contains a six-bit code point used to select an 
algorithm (a "per-hop behavior") to be applied to the datagram. 


The IPv6 over Low-Power Wireless Personal Area Networks RFC [RFC4919] 
and the Compression Format for IPv6 Datagrams in 6LOWPAN Networks 
document [6LOWPAN-HC] addresses IPv6 header compression and subnet 
architecture in at least some sensor networks, and may be appropriate 
to the Smart Grid Advanced Metering Infrastructure or other sensor 
domains. 


3.2.3.1. IPv6é Address Allocation and Assignment 


An IPv6é Address [RFC4291] may be administratively assigned using 
DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are. 
In addition, IPv6 addresses may also be autoconfigured. 
Autoconfiguration enables various models of network management that 
may be advantageous in different use cases. Autoconfiguration 
procedures are defined in [RFC4862] and [RFC4941]. IPv6 neighbors 
identify each others’ addresses using Neighbor Discovery (ND) 
[RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to 
secure these operations. 
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3.2.3.2. IPv6 Routing 


Routing for the IPv6 Internet is accomplished by routing applications 
that exchange connectivity information and build semi-static 


destination routing databases. If a datagram is directed to a given 
destination address, the address is looked up in the routing 
database, and the most specific ("longest") prefix found that 


contains it is used to identify the next-hop router or the end system 
to which it will be delivered. Routing is not generally implemented 

on hosts (although it can be); generally, a host sends datagrams to a 
router on its local network, and the router carries out the intent. 


IETF-specified routing protocols include RIP for IPv6 [RFC2080], 
IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 
[RFC2545]. Active research exists in mobile ad hoc routing, routing 
in low-power networks (sensors and Smart Grids), and other routing 
paradigms; these result in new protocols and modified forwarding 
paradigms. 


3.2.4. Routing for IPv4 and IPv6 
3.2.4.1. Routing Information Protocol 


The prototypical routing protocol used in the Internet has probably 
been the Routing Information Protocol [RFC1058]. People that use it 
today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2 
[RFC2453]. Briefly, RIP is a distance vector routing protocol that 
is based on a distributed variant of the widely known Bellman-Ford 
algorithm. In distance vector routing protocols, each router 
announces the contents of its route table to neighboring routers, 
which integrate the results with their route tables and re-announce 
them to others. It has been characterized as "routing by rumor", and 
suffers many of the ills we find in human gossip -- propagating stale 
or incorrect information in certain failure scenarios, and being in 
cases unresponsive to changes in topology. [RFC1058] provides 
guidance to algorithm designers to mitigate these issues. 


3.2.4.2. Open Shortest Path First 


The Open Shortest Path First (OSPF) routing protocol is one of the 
more widely used protocols in the Internet. OSPF is based on 
Dijkstra’s well known Shortest Path First (SPF) algorithm. It is 
implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6 
[RFC5340] for IPv6, and the Support of Address Families in OSPFv3 
[RFC5838] to enable [RFC5340] routing both IPv4 and IPvé6. 


The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is 
primarily that every router in the network constructs its view of the 
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network from first-hand knowledge rather than the "gossip" that 
distance vector protocols propagate. As such, the topology is 
quickly and easily changed by simply announcing the change. The 
disadvantage of SPF-based protocols is that each router must store a 
first-person statement of the connectivity of each router in the 
domain. 


3.2.4.3. ISO Intermediate System to Intermediate System 


The Intermediate System to Intermediate System (IS-IS) routing 
protocol is one of the more widely used protocols in the Internet. 
IS-IS is also based on Dijkstra’s SPF algorithm. It was originally 
specified as ISO DP 10589 for the routing of Connectionless Network 
Service (CLNS), and extended for routing in TCP/IP and dual 
environments [RFC1195], and more recently for routing of IPv6 
[RFC5308]. 


As with OSPF, the positives of any SPF-based protocol and 
specifically IS-IS are primarily that the network is described as a 
lattice of routers with connectivity to subnets and isolated hosts. 
It’s topology is quickly and easily changed by simply announcing the 
change, without the issues of "routing by rumor", since every host 
within the routing domain has a first-person statement of the 
connectivity of each router in the domain. The negatives are a 
corollary: each router must store a first-person statement of the 
connectivity of each router in the domain. 


3.2.4.4. Border Gateway Protocol 


The Border Gateway Protocol (BGP) [RFC4271] is widely used in the 
IPv4 Internet to exchange routes between administrative entities -- 
service providers, their peers, their upstream networks, and their 
customers -- while applying specific policy. Multiprotocol 
Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain 
Routing [RFC2545], multicast reachability information, and VPN 
information, among others. 


Considerations that apply with BGP deal with the flexibility and 
complexity of the policies that must be defined. Flexibility is a 
good thing; in a network that is not run by professionals, the 
complexity is burdensome. 


3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing 


The Mobile Ad Hoc working group of the IETF developed, among other 
protocols, Ad hoc On-Demand Distance Vector (AODV) Routing [RFC3561]. 
This protocol captured the minds of some in the embedded devices 
industry, but experienced issues in wireless networks such as 
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802.15.4 and 802.11’s Ad Hoc mode. As a result, it is in the process 
of being updated in the Dynamic MANET On-demand (DYMO) Routing 
protocol [DYMO]. 


AODV and DYMO are essentially reactive routing protocols designed for 
mobile ad hoc networks, and usable in other forms of ad hoc networks. 
They provide connectivity between a device within a distributed 
subnet and a few devices (including perhaps a gateway or router to 
another subnet) without tracking connectivity to other devices. In 
essence, routing is calculated and discovered upon need, and a host 
or router need only maintain the routes that currently work and are 
needed. 


3.2.4.6. Optimized Link State Routing Protocol 


The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a 
proactive routing protocol designed for mobile ad hoc networks, and 
can be used in other forms of ad hoc networks. It provides arbitrary 
connectivity between systems within a distributed subnet. As with 
protocols designed for wired networks, routing is calculated whenever 
changes are detected, and maintained in each router’s tables. The 
set of nodes that operate as routers within the subnet, however, are 
fairly fluid, and dependent on this instantaneous topology of the 
subnet. 


3.2.4.7. Routing for Low-Power and Lossy Networks 


The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) 

[RPL] is a reactive routing protocol designed for use in resource 
constrained networks. Requirements for resource constrained networks 
are defined in [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. 


Briefly, a constrained network is comprised of nodes that: 


o Are built with limited processing power and memory, and sometimes 
energy when operating on batteries. 


o Are interconnected through a low-data-rate network interface and 
are potentially vulnerable to communication instability and low 
packet delivery rates. 


o Potentially have a mix of roles such as being able to act as a 


host (i.e., generating traffic) and/or a router (i.e., both 
forwarding and generating RPL traffic). 
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3.2.5. IPv6é Multicast Forwarding and Routing 


IPv6 specifies both unicast and multicast datagram exchange. This 
uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] 
[RFC3590] [RFC3810] [RFC4604] to enable applications to join 
multicast groups, and for most applications uses Source-Specific 
Multicast [RFC4607] for routing and delivery of multicast messages. 


The mechanisms experimentally developed for reliable multicast in 
IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well. 


3.2.5.1. Protocol-Independent Multicast Routing 


A multicast routing protocol has two basic functions: building the 
multicast distribution tree and forwarding multicast traffic. 
Multicast routing protocols generally contain a control plane for 
building distribution trees, and a forwarding plane that uses the 
distribution tree when forwarding multicast traffic. 


The multicast model works as follows: hosts express their interest in 
receiving multicast traffic from a source by sending a Join message 
to their first-hop router. That router in turn sends a Join message 
upstream towards the root of the tree, grafting the router (leaf 
node) onto the distribution tree for the group. Data is delivered 
down the tree toward the leaf nodes, which forward it onto the local 
network for delivery. 


The initial multicast model deployed in the Internet was known as 
Any-Source Multicast (ASM). In the ASM model, any host could send to 
the group and inter-domain multicast was difficult. Protocols such 
as Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol 
Specification (Revised) [RFC3973] and Protocol Independent Multicast 
— Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] 
were designed for the ASM model. 


Many modern multicast deployments use Source-Specific Multicast (PIM- 
SSM) [RFC3569] [RFC4608]. In the SSM model, a host expresses interest 
in a "channel", which is comprised of a source (S) and a group (G). 


Distribution trees are rooted to the sending host (called an "(S,G) 
tree"). Since only the source S can send on to the group, SSM has 
inherent anti-jamming capability. In addition, inter-domain 


multicast is simplified since finding the (S,G) channel they are 
interested in receiving is the responsibility of the receivers 
(rather than the networks). This implies that SSM requires some form 
of directory service so that receivers can find the (S,G) channels. 
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3.2.6. Adaptation to Lower-Layer Networks and Link Layer Protocols 


In general, the layered architecture of the Internet enables the IPS 
to run over any appropriate layer two architecture. The ability to 
change the link or physical layer without having to rethink the 
network layer, transports, or applications has been a great benefit 
in the Internet. 


Examples of link layer adaptation technology include: 


Ethernet/IEEE 802.3: IPv4 has run on each link layer environment 
that uses the Ethernet header (which is to say 10 and 100 MBPS 
wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various 
versions of IEEE 802.11) using [RFC0894]. IPv6é does the same 
using [RFC2464]. 


PPP: The IETF has defined a serial line protocol, the Point-to-Point 
Protocol (PPP) [RFC1661], that uses High-Level Data Link Control 
(bit-synchronous or byte synchronous) framing. The IPv4 
adaptation specification is [RFC1332], and the IPv6 adaptation 
specification is [RFC5072]. Current use of this protocol is in 
traditional serial lines, authentication exchanges in DSL networks 
using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital 
Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) 
using PPP over SONET/SDH [RFC2615]. 


IEEE 802.15.4: The adaptation specification for IPv6 transmission 
over IEEE 802.15.4 Networks is [RFC4944]. 


Numerous other adaptation specifications exist, including ATM, Frame 
Relay, X.25, other standardized and proprietary LAN technologies, and 
others. 


3.3. Transport Layer 


This section outlines the functionality of UDP, TCP, SCTP, and DCCP. 
UDP and TCP are best known and most widely used in the Internet 
today, while SCTP and DCCP are newer protocols that were built for 
specific purposes. Other transport protocols can be built when 
required. 


3.3.1. User Datagram Protocol (UDP) 


The User Datagram Protocol [RFC0768] and the Lightweight User 
Datagram Protocol [RFC3828] are properly not "transport" protocols in 
the sense of "a set of rules governing the exchange or transmission 
of data electronically between devices". They are labels that 
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provide for multiplexing of applications directly on the IP layer, 
with transport functionality embedded in the application. 


Many exchange designs have been built using UDP, and many of them 
have not worked out. As a result, the use of UDP really should be 
treated as designing a new transport. Advice on the use of UDP in 
new applications can be found in Unicast UDP Usage Guidelines for 
Application Designers [RFC5405]. 


Datagram Transport Layer Security [RFC5238] can be used to prevent 
eavesdropping, tampering, or message forgery for applications that 
run over UDP. Alternatively, UDP can run over IPsec. 


3.3.2. Transmission Control Protocol (TCP) 


TCP [RFCO793] is the predominant transport protocol used in the 
Internet. It is "reliable", as the term is used in protocol design: 
it delivers data to its peer and provides acknowledgement to the 
sender, or it dies trying. It has extensions for Congestion Control 
[RFC5681] and Explicit Congestion Notification [RFC3168]. 


The user interface for TCP is a byte stream interface -- an 
application using TCP might "write" to it several times only to have 
the data compacted into a common segment and delivered as such to its 
peer. For message-stream interfaces, ACSE/ROSE uses the ISO 
Transport Service on TCP [RFC1006] [RFC2126] in the application. 


Transport Layer Security [RFC5246] can be used to prevent 
eavesdropping, tampering, or message forgery. Alternatively, TCP can 
run over IPsec. Additionally, [RFC4987] discusses mechanisms similar 
to SCTP’s and DCCP’s "cookie" approach that may be used to secure TCP 
sessions against flooding attacks. 


Finally, note that TCP has been the subject of ongoing research and 
development since it was written. The Roadmap for TCP Specification 
Documents [RFC4614] captures this history, and is intended to be a 
guide to current and future developers in the area. 


3.3.3. Stream Control Transmission Protocol (SCTP) 


SCTP [RFC4960] is a more recent reliable transport protocol that can 
be imagined as a TCP-like context containing multiple separate and 
independent message streams (unlike TCP’s byte streams). The design 
of SCTP includes appropriate congestion avoidance behavior and 
resistance to flooding and masquerade attacks. As it uses a message 
stream interface, it may also be more appropriate for the ISO 
Transport Service than using RFC 1006/2126 to turn TCP’s octet 
streams into a message interface. 
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SCTP offers several delivery options. The basic service is 
sequential non-duplicated delivery of messages within a stream, for 
each stream in use. Since streams are independent, one stream may 
pause due to head-of-line blocking while another stream in the same 
session continues to deliver data. In addition, SCTP provides a 
mechanism for bypassing the sequenced delivery service. User 
messages sent using this mechanism are delivered to the SCTP user as 
soon as they are received. 


SCTP implements a simple "cookie" mechanism intended to limit the 
effectiveness of flooding attacks by mutual authentication. This 
demonstrates that the application is connected to the same peer, but 
does not identify the peer. Mechanisms also exist for Dynamic 
Address Reconfiguration [RFC5061], enabling peers to change addresses 
during the session and yet retain connectivity. Transport Layer 
Security [RFC3436] can be used to prevent eavesdropping, tampering, 
or message forgery. Alternatively, SCTP can run over IPsec. 


3.3.4. Datagram Congestion Control Protocol (DCCP) 


DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that 
does not guarantee message delivery) that provides bidirectional 
unicast connections of congestion-controlled unreliable datagrams. 
DCCP is suitable for applications that transfer fairly large amounts 
of data and that can benefit from control over the tradeoff between 
timeliness and reliability. 


DCCP implements a simple "cookie" mechanism intended to limit the 
effectiveness of flooding attacks by mutual authentication. This 
demonstrates that the application is connected to the same peer, but 
does not identify the peer. Datagram Transport Layer Security 
[RFC5238] can be used to prevent eavesdropping, tampering, or message 
forgery. Alternatively, DCCP can run over IPsec. 


3.4. Infrastructure 
3.4.1. Domain Name System 


In order to facilitate network management and operations, the 
Internet community has defined the Domain Name System (DNS) [RFC1034] 
[RFC1035]. Names are hierarchical: a name like example.com is found 
registered with a .com registrar, and within the associated network 
other names like baldur.cincinatti.example.com can be defined, with 
obvious hierarchy. Security extensions, which allow a registry to 
sign the records it contains and in so doing demonstrate their 
authenticity, are defined by the DNS Security Extensions [RFC4033] 
[RFC4034] [RFC4035]. 
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Devices can also optionally update their own DNS record. For 
example, a sensor that is using Stateless Address Autoconfiguration 
[RFC4862] to create an address might want to associate it with a name 
using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update 
[RFC3007]. 


3.4.2. Dynamic Host Configuration 


As discussed in Section 3.2.2, IPv4 address assignment is generally 


performed using DHCP [RFC2131]. By contrast, Section 3.2.3 points 
out that IPv6 address assignment can be accomplished using either 
autoconfiguration [RFC4862] [RFC4941] or DHCPv6é [RFC3315]. The best 


argument for the use of autoconfiguration is a large number of 
systems that require little more than a random number as an address; 
the argument for DHCP is administrative control. 


There are other parameters that may need to be allocated to hosts 
requiring administrative configuration; examples include the 
addresses of DNS servers, keys for Secure DNS, and Network Time 


servers. 


3.4.3. Network Time 


The Network Time Protocol was originally designed by Dave Mills of 
the University of Delaware and CSNET, implementing a temporal metric 
in the Fuzzball Routing Protocol and generally coordinating time 
experiments. The current versions of the time protocol are the 
Network Time Protocol [RFC5905]. 


3.5. Network Management 


The IETF has developed two protocols for network management: SNMP and 
NETCONF. SNMP is discussed in Section 3.5.1, and NETCONF is 
discussed in Section 3.5.2. 

3.5.1. Simple Network Management Protocol (SNMP) 
The Simple Network Management Protocol, originally specified in the 
late 1980’s and having passed through several revisions, is specified 


in several documents: 


o An Architecture for Describing Simple Network Management Protocol 
(SNMP) Management Frameworks [RFC3411] 


o Message Processing and Dispatching [RFC3412] 


o SNMP Applications [RFC3413] 
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o User-based Security Model (USM) for SNMP version 3 [RFC3414] 
o View-based Access Control Model (VACM) [RFC3415] 
o Version 2 of the SNMP Protocol Operations [RFC3416] 
o Transport Mappings [RFC3417] 
o Management Information Base (MIB) [RFC3418] 
It provides capabilities for polled and event-driven activities, and 
for both monitoring and configuration of systems in the field. 
Historically, it has been used primarily for monitoring nodes in a 
network. Messages and their constituent data are encoded using a 
profile of ASN.1. 

3.5.2. Network Configuration (NETCONF) Protocol 
The NETCONF Configuration Protocol is specified in one basic 
document, with supporting documents for carrying it over the IPS. 
These documents include: 


o NETCONF Configuration Protocol [RFC4741] 


o Using the NETCONF Configuration Protocol over Secure SHell (SSH) 
[RFC4742] 


o Using NETCONF over the Simple Object Access Protocol (SOAP) 
[RFC4743] 


o Using the NETCONF Protocol over the Blocks Extensible Exchange 
Protocol (BEEP) [RFC4744] 


o NETCONF Event Notifications [RFC5277] 
o NETCONF over Transport Layer Security (TLS) [RFC5539] 
o Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717] 


NETCONF was developed in response to operator requests for a common 
configuration protocol based on ASCII text, unlike ASN.1. In 
essence, it carries XML-encoded remote procedure call (RPC) data. In 
response to Smart Grid requirements, there is consideration of a 
variant of the protocol that could be used for polled and event- 
driven management activities, and for both monitoring and 
configuration of systems in the field. 
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3.6. Service and Resource Discovery 


Service and resource discovery are among the most important protocols 
for constrained resource self-organizing networks. These include 
various sensor networks as well as the Home Area Networks (HANs), 
Building Area Networks (BANs), and Field Area Networks (FANs) 
envisioned by Smart Grid architects. 


3.6.1. Service Discovery 


Service discovery protocols are designed for the automatic 
configuration and detection of devices, and the services offered by 
the discovered devices. In many cases service discovery is performed 
by so-called "constrained resource" devices (i.e., those with limited 
processing power, memory, and power resources). 


In general, service discovery is concerned with the resolution and 
distribution of host names via multicast DNS [MULTICAST-DNS] and the 
automatic location of network services via DHCP (Section 3.4.2), the 
DNS Service Discovery (DNS-SD) [DNS-SD] (part of Apple’s Bonjour 
technology), and the Service Location Protocol (SLP) [RFC2608]. 


3.6.2. Resource Discovery 
Resource Discovery is concerned with the discovery of resources 
offered by end-points and is extremely important in machine-to- 
machine closed-loop applications (i.e., those with no humans in the 
loop). The goals of resource discovery protocols include: 
o Simplicity of creation and maintenance of resources 
o Commonly understood semantics 
o Conformance to existing and emerging standards 
o International scope and applicability 
o Extensibility 
o Interoperability among collections and indexing systems 
The Constrained Application Protocol (CoAP) [COAP] is being developed 
in IETF with these goals in mind. In particular, CoAP is designed 
for use in constrained resource networks and for machine-to-machine 
applications such as smart energy and building automation. It 
provides a RESTful transfer protocol [RESTFUL], a built-in resource 


discovery protocol, and includes web concepts such as URIs and 
content-types. CoAP provides both unicast and multicast resource 
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discovery and includes the ability to filter on attributes of 
resource descriptions. Finally, CoAP resource discovery can also be 
used to discover HTTP resources. 


For simplicity, CoAP makes the assumption that all CoAP servers 
listen on the default CoAP port or otherwise have been configured or 
discovered using some general service discovery mechanism such as DNS 
Service Discovery (DNS-SD) [DNS-SD]. 


Resource discovery in CoAP is accomplished through the use of well- 
known resources that describe the links offered by a CoAP server. 
CoAP defines a well-known URI for discovery: "/.well-known/r" 
[RFC5785]. For example, the query [GET /.well-known/r] returns a 
list of links (representing resources) available from the queried 
CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns 
the resources with the name Voltage. 


3.7. Other Applications 


There are many applications that rely on the IP infrastructure, but 
are not properly thought of as part of the IP infrastructure itself. 
These applications may be useful in the context of the Smart Grid. 
The choices made when constructing a profile of the Internet Profile 
Suite may impact how such applications could be used. Some of them, 
not by any means an exhaustive list, are discussed here. 


3.7.1. Session Initiation Protocol 


The Session Initiation Protocol [RFC3261] [RFC3265] [RFC3853] 
[RFC4320] [RFC4916] [RFC5393] [RFC5621] is an application layer 
control (signaling) protocol for creating, modifying, and terminating 
multimedia sessions on the Internet, and is meant to be more scalable 
than H.323. Multimedia sessions can be voice, video, instant 
messaging, shared data, and/or subscriptions of events. SIP can run 
on top of TCP, UDP, SCTP, or TLS over TCP. SIP is independent of the 
transport layer, and independent of the underlying IPv4/v6 version. 
In fact, the transport protocol used can change as the SIP message 
traverses SIP entities from source to destination. 


SIP itself does not choose whether a session is voice or video, nor 
does it identify the actual endpoints’ IP addresses. The Session 
Description Protocol (SDP) [RFC4566] is intended for those purposes. 
Within the SDP, which is transported by SIP, codecs are offered and 
accepted (or not), and the port number and IP address at which each 
endpoint wants to receive their Real-time Transport Protocol (RTP) 
[RFC3550] packets are determined. The introduction of Network 
Address Translation (NAT) technology into the profile, whether IPv4/ 
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IPv4, IPv4/IPv6 as described in Section 3.2.1.3, or IPv6/IPv6, 
increases the complexity of SIP/SDP deployment. This is further 
discussed in [RFC2993] and [RFC5626]. 


3.7.2. Extensible Messaging and Presence Protocol 


The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a 
protocol for streaming Extensible Markup Language (XML) elements in 
order to exchange structured information in close to real time 
between any two network endpoints. Since XMPP provides a 
generalized, extensible framework for exchanging XML data, it has 
been proposed as an application structure for interchange between 
embedded devices and sensors. It is currently used for Instant 
Messaging and Presence [RFC6121] and a wide variety of real-time 
communication modes. These include multi-user chat, publish- 
subscribe, alerts and notifications, service discovery, multimedia 
session management, device configuration, and remote procedure calls. 
XMPP supports channel encryption using TLS [RFC5246] and strong 
authentication (including PKIX certificate authentication) using SASL 
[RFC4422]. It also makes use of Unicode-compliant addresses and 
UTF-8 [RFC3629] data exchange for internationalization. 


XMPP allows for End-to-End Signing and Object Encryption [RFC3923], 
access to objects named using Uniform Resource Names (URN) [RFC4854], 
use of Internationalized Resource Identifiers (IRIs) and Uniform 
Resource Identifiers (URIs) [RFC5122], and the presentation of 
Notifications [RFC5437]. 


3.7.3. Calendaring 


Internet calendaring, as implemented in Apple iCal, Microsoft Outlook 
and Entourage, and Google Calendar, is specified in Internet 
Calendaring and Scheduling Core Object Specification (iCalendar) 
[RFC5545] and is in the process of being updated to an XML schema in 
iCalendar XML Representation [xCAL]. Several protocols exist to 
carry calendar events, including the iCalendar Transport-—Independent 
Interoperability Protocol (iTIP) [RFC5546], the iCalendar Message- 
Based Interoperability Protocol (iMIP) [RFC6047], and open source 
work on the Atom Publishing Protocol [RFC5023]. 


4. A Simplified View of the Business Architecture 


The Internet is a network of networks in which networks are 
interconnected in specific ways and are independently operated. It 
is important to note that the underlying Internet architecture puts 
no restrictions on the ways that networks are interconnected; 
interconnection is a business decision. As such, the Internet 
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interconnection architecture can be thought of as a "business 
structure" for the Internet. 


Central to the Internet business structure are the networks that 
provide connectivity to other networks, called "transit networks". 
These networks sell bulk bandwidth and routing services to each other 
and to other networks as customers. Around the periphery of the 
transit network are companies, schools, and other networks that 
provide services directly to individuals. These might generally be 
divided into "enterprise networks" and "access networks"; enterprise 
networks provide "free" connectivity to their own employees or 
members, and also provide them a set of services including electronic 
mail, web services, and so on. Access networks sell broadband 
connectivity (DSL, Cable Modem, 802.11 wireless, or 3GPP wireless) or 
"dial" services (including PSTN dial-up and ISDN) to subscribers. 

The subscribers are typically either residential or small office/home 
office (SOHO) customers. Residential customers are generally 
entirely dependent on their access provider for all services, while a 
SOHO buys some services from the access provider and may provide 
others for itself. Networks that sell transit services to nobody 


else -- SOHO, residential, and enterprise networks -- are generally 
refereed to as "edge networks"; transit networks are considered to be 
part of the "core" of the Internet, and access networks are between 
the two. This general structure is depicted in Figure 3. 
/ \ / \ 
/--\ / \ / \ 
|SOHO|---+ Access | |Enterprise| 
\--/ | Service | | Network | 
/--\ | Provider | | | 
| Home | --—+ — | | 
\--/ \ +---+ +---+ / 
\ / / \ \ / 
SSSaas | Transit | Sn 
| Service | 
| Provider | 
| | 
\ / 
\ / 


Figure 3: Conceptual Model of Internet Businesses 
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A specific example is shown in a traceroute from a home to a nearby 
school. Internet connectivity in Figure 4 passes through 
o the home network, 


o Cox Communications, an access network using Cable Modem 
technology, 


o TransitRail, a commodity peering service for research and 
education (R&E) networks, 


o Corporation for Education Network Initiatives in California 
(CENIC), a transit provider for educational networks, and 


o the University of California at Santa Barbara, which in this 
context might be viewed as an access network for its students and 
faculty or as an enterprise network. 


<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu 
traceroute to web.ucsb.edu (128.111.24.41), 

64 hops max, 40 byte packets 
fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms 
wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms 
68.6.13.101 
68.6.13.129 
langbbr01-as0O.r2.la.cox.net 
calren46-cust.lsanca0l.transitrail.net 
dc-lax-corel—-lax-peerl-ge.cenic.net 
dc-lax-agg1-—-lax-corel-ge.cenic.net 
dc-ucsb--dc-lax-dc2.cenic.net 
r2--r1--1.commserv.ucsb.edu 


574-c--r2--2.commserv.ucsb.edu 
xk kK * 


bh 
DOWMDANHDAUBWNE 


a 
N H 


Figure 4: Traceroute from Residential Customer to Educational 
Institution 


Another specific example could be shown in a traceroute from the home 
through a Virtual Private Network (VPN tunnel) from the home, 
crossing Cox Cable (an access network) and Pacific Bell (a transit 
network), and terminating in Cisco Systems (an enterprise network); a 
traceroute of the path doesn’t show that as it is invisible within 
the VPN and the contents of the VPN are invisible, due to encryption, 
to the networks on the path. Instead, the traceroute in Figure 5 is 
entirely within Cisco’s internal network. 
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<stealth-10-32-244-218:"> fred% traceroute irp-view13 
traceroute to irp-viewl3.cisco.com (171.70.120.60), 
64 hops max, 40 byte packets 
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms 
<tunneled path through Cox and Pacific Bell> 


2 KKKK 

3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms... 
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms 

5 sjc20-a5-gwl (10.32.136.21) 23.205 ms 

6 sjcl2-abb4-gwl-t2-7 (10.32.0.189) 46.028 ms 

7 sjc5-sbb4-gwi-ten8-2 (171.*.*.*) 26.700 ms 

8 sjcl2-dc5-gw2-ten3-1 

9 sjc5-dc4-gwl-ten8-1 

10 irp-view13 


Figure 5: Traceroute across VPN 


Note that in both cases, the home network uses private address space 
[RFC1918] while other networks generally use public address space, 
and that three middleware technologies are in use here. These are 
the uses of a firewall, a Network Address Translator (NAT), anda 
Virtual Private Network (VPN). 


Firewalls are generally sold as and considered by many to be a 
security technology. This is based on the fact that a firewall 
imposes a border between two administrative domains. Typically, a 
firewall will be deployed between a residential, SOHO, or enterprise 
network and its access or transit provider. In its essence, a 
firewall is a data diode, imposing a policy on what sessions may pass 
between a protected domain and the rest of the Internet. Simple 
policies generally permit sessions to be originated from the 
protected network but not from the outside; more complex policies may 
permit additional sessions from the outside, such as electronic mail 
to a mail server or a web session to a web server, and may prevent 
certain applications from global access even though they are 
originated from the inside. 


Note that the effectiveness of firewalls remains controversial. 

While network managers often insist on deploying firewalls as they 
impose a boundary, others point out that their value as a security 
solution is debatable. This is because most attacks come from behind 
the firewall. In addition, firewalls do not protect against 
application layer attacks such as viruses carried in email. Thus, as 
a security solution, firewalls are justified as a layer in defense in 
depth. That is, while an end system must in the end be responsible 
for its own security, a firewall can inhibit or prevent certain kinds 
of attacks, for example the consumption of CPU time on a critical 
server. 
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Key documents describing firewall technology and the issues it poses 
include: 

o IP Multicast and Firewalls [RFC2588] 

o Benchmarking Terminology for Firewall Performance [RFC2647] 

o Behavior of and Requirements for Internet Firewalls [RFC2979] 
o Benchmarking Methodology for Firewall Performance [RFC3511] 


o Mobile IPv6 and Firewalls: Problem Statement [RFC4487] 


o NAT and Firewall Traversal Issues of Host Identity Protocol 
Communication [RFC5207] 


Network Address Translation is a technology that was developed in 
response to ISP behaviors in the mid-1990’s; when [RFC1918] was 
published, many ISPs started handing out single or small numbers of 
addresses, and edge networks were forced to translate. In time, this 
became considered a good thing, or at least not a bad thing; it 
amplified the public address space, and it was sold as if it were a 
firewall. It of course is not; while traditional dynamic NATs only 
translate between internal and external session address/port tuples 
during the detected duration of the session, that session state may 
exist in the network much longer than it exists on the end system, 
and as a result constitutes an attack vector. The design, value, and 
limitations of network address translation are described in: 


o IP Network Address Translator Terminology and Considerations 
[RFC2663] 


o Traditional IP Network Address Translator [RFC3022] 


o Protocol Complications with the IP Network Address Translator 
[RFC3027] 


o Network Address Translator Friendly Application Design Guidelines 
[RFC3235] 


o IAB Considerations for Network Address Translation [RFC3424] 


o IPsec-Network Address Translation Compatibility Requirements 
[RFC3715] 


o Network Address Translation Behavioral Requirements for Unicast 
UDP [RFC4787] 
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7. 


7. 


o State of Peer-to-Peer Communication across Network Address 
Translators [RFC5128] 


o IP Multicast Requirements for a Network Address Translator anda 
Network Address Port Translator [RFC5135] 


Virtual Private Networks come in many forms; what they have in common 
is that they are generally tunneled over the Internet backbone, so 
that as in Figure 5, connectivity appears to be entirely within the 
edge network although it is in fact across a service provider’s 
network. Examples include IPsec tunnel-mode encrypted tunnels, IP- 
in-IP or GRE tunnels, and MPLS LSPs [RFC3031] [RFC3032]. 


Security Considerations 


Security is addressed in some detail in Section 2.2 and Section 3.1. 
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Appendix A. Example: Advanced Metering Infrastructure 


This appendix provides a worked example of the use of the Internet 
Protocol Suite in a network such as the Smart Grid’s Advanced 
Metering Infrastructure (AMI). There are several possible models. 


Figure 6 shows the structure of the AMI as it reaches out towards a 
set of residences. In this structure, we have the home itself and 
its Home Area Network (HAN), the Neighborhood Area Network (NAN) that 
the utility uses to access the meter at the home, and the utility 
access network that connects a set of NANs to the utility itself. 

For the purposes of this discussion, assume that the NAN contains a 
distributed application in a set collectors, which is of course only 
one way the application could be implemented. 


A thermostats, appliances, etc 

| ------ +----------------------------------- 

| | 

| "HAN" | <--- Energy Services Interface (ESI) 

| +---+---+ 

| | Meter | Meter is generally an ALG between the AMI and the HAN 

+---+---+ 

Vv \ 
--- \ 
A No [ihe 

| w li a7 

"NAN" +--+-+-+---+ Likely a router but could 
| |Collector | be a front-end application 
V +----+----- + gateway for utility 
--- \ 
A \ | / 

| Nall! ah 

"AMI" +--+-+-+--+ 

| | amr | 

| | Headend | 
V +--------- + 


Figure 6: The HAN, NAN, and Utility in the Advanced Metering 
Infrastructure 


There are several questions that have to be answered in describing 
this picture, which given possible answers yield different possible 


models. They include at least: 


o How does Demand Response work? Either: 
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* The utility presents pricing signals to the home, 


* The utility presents pricing signals to individual devices 
(e.g., a Pluggable Electric Vehicle), 


* The utility adjusts settings on individual appliances within 
the home. 


o How does the utility access meters at the home? 


* The AMI Headend manages the interfaces with the meters, 
collecting metering data and passing it on to the appropriate 
applications over the Enterprise Bus, or 


* Distributed application support ("collectors") might access and 
summarize the information; this device might be managed by the 
utility or by a service between the utility and its customers. 


In implementation, these models are idealized; reality may include 
some aspects of each model in specified cases. 


The examples include: 


1. Appendix A.2 presumes that the HAN, the NAN, and the utility’s 
network are separate administrative domains and speak application 
to application across those domains. 


2. Appendix A.3 repeats the first example, but presuming that the 
utility directly accesses appliances within the HAN from the 
collector. 


3. Appendix A.4 repeats the first example, but presuming that the 
collector directly forwards traffic as a router in addition to 
distributed application chores. Note that this case implies 
numerous privacy and security concerns and as such is considered 
a less likely deployment model. 


A.1. How to Structure a Network 


A key consideration in the Internet has been the development of new 
link layer technologies over time. The ARPANET originally used a BBN 
proprietary link layer called BBN 1822 [r1822]. In the late 1970's, 
the ARPANET switched to X.25 as an interface to the 1822 network. 
With the deployment of the IEEE 802 series technologies in the early 
1980’s, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE 
802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of 
various kinds, Frame Relay, and ATM. A key issue in this evolution 
was that the applications developed to run on the Internet use APIs 
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related to the IPS, and as a result require little or no change to 
continue operating in a new link layer architecture or a mixture of 
them. 


The Smart Grid is likely to see a similar evolution over time. 
Consider the Home Area Network (HAN) as a readily understandable 
small network. At this juncture, technologies proposed for 
residential networks include IEEE P1901, various versions of IEEE 
802.15.4, and IEEE 802.11. It is reasonable to expect other 
technologies to be developed in the future. As the Zigbee Alliance 
has learned (and as a resulted incorporated the IPS in Smart Energy 
Profile 2.0), there is significant value in providing a virtual 
address that is mapped to interfaces or nodes attached to each of 
those technologies. 
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Figure 7: Two Views of a Home Area Network 


There are two possible communication models within the HAN, both of 


which are likely to be useful. 
each other, 


or they may be managed by some central controller. 


Devices may communicate directly with 
An 


example of direct communications might be a light switch that 


directly commands a lamp to turn on or off. 


An example of indirect 


communications might be a control application in a Customer or 


Building that accepts telemetry from a thermostat, 


of policy, 
addition, 


and controls the heating and air conditioning systems. 
there are high-end appliances in the market today that use 
residential broadband to communicate with their manufacturers, 


applies some form 
In 


and 


obviously the meter needs to communicate with the utility. 


Baker & Meyer 


Informational 


[Page 61] 


RFC 6272 Internet Protocols for the Smart Grid June 2011 


Figure 7 shows two simple networks, one of which uses IEEE 802.15.4 
and IEEE 1901 domains, and one of which uses an arbitrary LAN within 
the home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE 
1901, IEEE 802.11, or anything else that made sense in context. Both 
show the connectivity between them as a router separate from the 
energy management system (EMS). This is for clarity; the two could 
of course be incorporated into a single system, and one could imagine 
appliances that want to communicate with their manufacturers 
supporting both a HAN interface and a WiFi interface rather than 
depending on the router. These are all manufacturer design 
decisions. 


A.1.1. HAN Routing 


The HAN can be seen as communicating with two kinds of non-HAN 
networks. One is the home LAN, which may in turn be attached to the 
Internet, and will generally either derive its prefix from the 
upstream ISP or use a self-generated Unique Local Addressing (ULA). 
Another is the utility’s NAN, which through an ESI provides utility 
connectivity to the HAN; in this case the HAN will be addressed by a 
self-generated ULA (note, however, that in some cases ESI may also 
provide a prefix via DHCP [RFC3315]). In addition, the HAN will have 
link-local addresses that can be used between neighboring nodes. In 
general, an HAN will be comprised of both 802.15.4, 802.11, and 
possibly other networks. 


The ESI is a node on the user’s residential network, and will not 
typically provide stateful packet forwarding or firewall services 
between the HAN and the utility network(s). In general, the ESI is a 
node on the home network; in some cases, the meter may act as the 
ESI. However, the ESI must be capable of understanding that most 
home networks are not 802.15.4 enabled (rather, they are typically 
802.11 networks), and that it must be capable of setting up ad hoc 
networks between various sensors in the home (e.g., between the meter 
and say, a thermostat) in the event there aren’t other networks 
available. 


A.1.2. HAN Security 


In any network, we have a variety of threats and a variety of 
possible mitigations. These include, at minimum: 


Link Layer: Why is your machine able to talk in my network? The 
WiFi SSIDs often use some form of authenticated access control, 
which may be a simple encrypted password mechanism or may use a 
combination of encryption and IEEE 802.1X+EAP-TLS Authentication/ 
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Authorization to ensure that only authorized communicants can use 
it. If a LAN has a router attached, the router may also implement 
a firewall to filter remote accesses. 


Network Layer: Given that your machine is authorized access to my 
network, why is your machine talking with my machine? IPsec is a 
way of ensuring that computers that can use a network are allowed 
to talk with each other, may also enforce confidentiality, and may 
provide VPN services to make a device or network appear to be part 
of a remote network. 


Application: Given that your machine is authorized access to my 
network and my machine, why is your application talking with my 
application? The fact that your machine and mine are allowed to 
talk for some applications doesn’t mean they are allowed to for 
all applications. (D) TLS, https, and other such mechanisms enable 
an application to impose application-to-application controls 
similar to the network layer controls provided by IPsec. 


Remote Application: How do I know that the data I received is the 
data you sent? Especially in applications like electronic mail, 
where data passes through a number of intermediaries that one may 
or may not really want munging it (how many times have you seen a 
URL broken by a mail server?), we have tools (DKIM, S/MIME, and 
W3C XML Signatures to name a few) to provide non-repudiability and 
integrity verification. This may also have legal ramifications: 
if a record of a meter reading is to be used in billing, and the 
bill is disputed in court, one could imagine the court wanting 
proof that the record in fact came from that meter at that time 
and contained that data. 


Application-specific security: In addition, applications often 
provide security services of their own. The fact that I can 
access a file system, for example, doesn’t mean that I am 
authorized to access everything in it; the file system may well 
prevent my access to some of its contents. Routing protocols like 
BGP are obsessed with the question "what statements that my peer 
made am I willing to believe", and monitoring protocols like SNMP 
may not be willing to answer every question they are asked, 
depending on access configuration. 


Devices in the HAN want controlled access to the LAN in question for 
obvious reasons. In addition, there should be some form of mutual 
authentication between devices -- the lamp controller will want to 
know that the light switch telling it to change state is the right 
light switch, for example. The EMS may well want strong 
authentication of accesses -- the parents may not want the children 
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changing the settings, and while the utility and the customer are 
routinely granted access, other parties (especially parties with 
criminal intent) need to be excluded. 


A.2. Model 1: AMI with Separated Domains 


With the background given in Appendix A.1, we can now discuss the use 
of IP (IPv4 or IPv6) in the AMI. 


In this first model, consider the three domains in Figure 6 to 
literally be separate administrative domains, potentially operated by 
different entities. For example, the NAN could be a WiMAX network 
operated by a traditional telecom operator, the utility’s network 
(including the collector) is its own, and the residential network is 
operated by the resident. In this model, while communications 
between the collector and the Meter are normal, the utility has no 
other access to appliances in the home, and the collector doesn’t 
directly forward messages from the NAN upstream. 


In this case, as shown in Figure 7, it would make the most sense to 
design the collector, the Meter, and the EMS as hosts on the NAN -- 
design them as systems whose applications can originate and terminate 
exchanges or sessions in the NAN, but not forward traffic from or to 
other devices. 


In such a configuration, Demand Response has to be performed by 
having the EMS accept messages such as price signals from the "pole 
top", apply some form of policy, and then orchestrate actions within 
the home. Another possibility is to have the EMS communicate with 
the ESI located in the meter. If the thermostat has high demand and 
low demand (day/night or morning/day/evening/night) settings, Demand 
Response might result in it moving to a lower demand setting, and the 
EMS might also turn off specified circuits in the home to diminish 
lighting. 


In this scenario, Quality of Service (QoS) issues reportedly arise 
when high precedence messages must be sent through the collector to 
the home; if the collector is occupied polling the meters or doing 
some other task, the application may not yield control of the 
processor to the application that services the message. Clearly, 
this is either an application or an Operating System problem; 
applications need to be designed in a manner that doesn’t block high 
precedence messages. The collector also needs to use appropriate NAN 
services, if they exist, to provide the NAN QoS it needs. For 
example, if WiMax is in use, it might use a routine-level service for 
normal exchanges but a higher precedence service for these messages. 
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A.3. Model 2: AMI with Neighborhood Access to the Home 


In this second model, let’s imagine that the utility directly 
accesses appliances within the HAN. Rather than expect an EMS to 
respond to price signals in Demand Response, it directly commands 
devices like air conditioners to change state, or throws relays on 
circuits to or within the home. 


+---------- + +--+ +--+ +--+ 
Meter | |D1| |p2| |p3| 
+----- +—---+ ++-+ ++-+ ++-+ 
| | | | 
----+-+------- +----+----+---- IEEE 802.15.4 
| 
+--+---+ 
+------ /------ NAN 
Router | 
+------ /------ Residential Broadband 
+--+---+ 
| 
----+--+------ +----+----+---- IEEE P1901 


| | | | 
+-+-+  ++-+ ++-+ 44-4 
| EMS | |D4| |p5| |De] 
+---+ +--+ +--+ +--+ 


Figure 8: Home Area Network 


In this case, as shown in Figure 8, the Meter and EMS act as hosts on 
the HAN, and there is a router between the HAN and the NAN. 


As one might imagine, there are serious security considerations in 
this model. Traffic between the NAN and the residential broadband 
network should be filtered, and the issues raised in Appendix A.1.2 
take on a new level of meaning. One of the biggest threats may be a 
legal or at least a public relations issue; if the utility 
intentionally disables a circuit in a manner or at a time that 
threatens life (the resident’s kidney dialysis machine is on it, ora 
respirator, for example), the matter might make the papers. 
Unauthorized access could be part of juvenile pranks or other things 
as well. So one really wants the appliances to only obey commands 
under strict authentication/authorization controls. 


In addition to the QoS issues raised in Appendix A.2, there is the 


possibility of queuing issues in the router. In such a case, the IP 
datagrams should probably use the Low-Latency Data Service Class 
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described in [RFC4594], and let other traffic use the Standard 
Service Class or other service classes. 


A.4. Model 3: Collector Is an IP Router 


In this third model, the relationship between the NAN and the HAN is 
either as in Appendix A.2 or Appendix A.3; what is different is that 
the collector may be an IP router. In addition to whatever 
autonomous activities it is doing, it forwards traffic as an IP 
router in some cases. 


Analogous to Appendix A.3, there are serious security considerations 
in this model. Traffic being forwarded should be filtered, and the 
issues raised in Appendix A.1.2 take on a new level of meaning -- but 
this time at the utility mainframe. Unauthorized access is likely 
similar to other financially-motivated attacks that happen in the 
Internet, but presumably would be coming from devices in the HAN that 
have been co-opted in some way. One really wants the appliances to 
only obey commands under strict authentication/authorization 
controls. 


In addition to the QoS issues raised in Appendix A.2, there is the 
possibility of queuing issues in the collector. In such a case, the 
IP datagrams should probably use the Low-Latency Data Service Class 
described in [RFC4594], and let other traffic use the Standard 
Service Class or other service classes. 
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